安定したAWSアカウントのデータベース利用費が2024年3月から増えていたらRDS延長サポートを要チェック!

Amazon Aurora/RDSでは、2024年3月からRDS延長サポートが導入され、標準サポート後は自動的に有償サポートが継続されるようになりました。標準サポートの期限切れに気づかないままRDS延長サポートを払い続けていることに気づいたアナタへ。

#Amazon RDS

#Amazon Aurora

#AWS

#PostgreSQL

#MySQL

quiver

2024.03.21

2024年3月からAmazon RDS延長サポートがオプトアウトで導入され、従来のサポート期間終了後も最大で3年間サポートを受け続けられるようになりました。このサービスは自動登録され、費用も伴うことから、2024年3月以降に費用の高騰で初めて気づいたお客様もいるかもしれません。

本記事では、Amazon RDS延長サポートの狙い、費用、メジャーアップグレード方法について解説します。

特に、以下のケースは注意が必要です

db.t3.smallなどT系の小さなインスタンスタイプを利用
インフラ予算が厳密に設定されている

Amazon RDS 延長サポートとは

AWSが提供するMySQL/PostgreSQLのマネージドサービスでは、各メジャーバージョンのコミュニティ版よりも長い期間にかけてバグやセキュリティに対してパッチを提供してきました。2024年3月からは新たにAmazon RDS 延長サポートという仕組みが導入され、AWS独自の従来型サポート期間が終了したあとも、最大で3年間パッチ提供されるようになりました。MySQL 5.7を例に取ると、2016年の2月下旬にリリースされたRDS MySQL 5.7は、サポートの期限が2024年2月末から2026年2月に伸び、約10年にわたってサポートされるようになりました。

データベースのメジャーアップグレードは人的にも時間的にも多くのリソースを伴います。RDS延長サポートの費用を代償に、データベースのメジャーアップグレードサイクルを長くしたり、サービス終了まで同じメジャーバージョンを使い続け、メジャーアップグレードの対応リソースをプロダクト開発に回せます。

このRDS延長サポートはオプトアウトのため、利用者がメジャーアップグレードしなければ自動登録されます。初年度からRDS/Auroraインスタンスと同等の費用が発生し、3年目はさらにその倍です。AWSからの請求明細を日頃からチェックしていないと、RDS延長サポートの自動登録によりインフラコストが増えていることを見過ごしてしまうかもしれません。対象となるのは、古いデータベースが動いているような昔から稼働しているアカウントです。

RDS延長サポートの明細を確認

AWSコンソール「請求とコスト管理 > 請求書」のRelational Database Service(RDS)には、インスタンス利用費と一緒にRDS延長サポート費を確認できます。

Amazon RDS for MySQL 5.7は2024年3月からRDS延長サポートに自動登録されています。

明細には RDS Extended Support for MySQL 5.7 in Year 1, Year 2とあります。

同様に、PostgreSQL 11も2024年4月からRDS延長サポートに自動登録されています。

明細には RDS Extended Support for PostgreSQL 11 in Year 1, Year 2とあります。

RDS延長サポートの費用

延長サポートの費用はvCPU数と線形に発生し、単価は最初の2年と3年目の2段階構成であり、3年目は最初2年の2倍です。また、単価はインスタンスと同じくリージョンによって異なります。東京・大阪リージョンは1~2年目が$0.12/vCPU-Hour、3年目が$0.24/vCPU-Hourです。

vCPUも考慮したインスタンスあたりのサポート費はオンデマンドインスタンスと同程度かかります。注意点は以下です。

マルチAZ構成の場合、サポート費も2インスタンス分かかる
T系インスタンスのlargeサイズ以下のvCPU数は2に固定。インスタンス費に比べてサポート費の占める割合が高くなる

東京リージョンでRDS利用費を実際に試算してみましょう。

db.m5.large の RDS MySQL 5.7 をマルチAZ構成で起動している場合

db.m5.large のvCPU数は2のため、1~2年目の延長サポート単価は $0.12/vCPU * 2 vCPU = $0.24/時間です。

インスタンスのサイズが大きくなるにつれて、vCPU数もオンデマンド単価も倍々に増えるため、オンデマンド単価とサポート単価の比率はlargeサイズによらず一定で、最初の2年はインスタンス:サポート≒1:1、3年目は1:2です。

モデル	vCPU	メモリ(GiB)	オンデマンド費	サポート費(1~2年目)	サポート費(3年目)	比率(1~2年目)	比率(3年目)
db.m5.large	2	8	0.235	0.24	0.48	1.02	2.04
db.m5.xlarge	4	16	0.47	0.48	0.96	1.02	2.04
...
db.m5.12xlarge	96	192	11.28	11.52	23.04	1.02	2.04

m5以外の非T系インスタンスでも、オンデマンド費と延長サポート費の比率はほぼ同じです。 試算しやすいですね。

マルチAZ構成の場合、プライマリとスタンバイの2インスタンスが存在します。インスタンス費用が2台分かかるように、サポート費用も2台分かかります。

インスタンスに付随する延長サポートの費用を合算すると、(インスタンス $0.235 +サポート $0.24)/インスタンス x 2 インスタンス = $0.95/時間です。

db.t3.micro の RDS MySQL 5.7 を1台構成で起動している場合

開発環境等で小さなT系インスタンスを利用している場合は急激なコスト増に注意が必要です。

db.t3.microのオンデマンド単価は $0.026/時間です。

インスタンスのサイズが大きくなるにつれて、オンデマンド単価もメモリサイズも倍々に増えますが、large以下のvCPU数は2に固定されています。vCPU数が1, 0.5, 0.25 とならないことにご留意ください。そのため、db.t3.microの1~2年目の延長サポート単価はdb.t3.largeと同じ $0.12/vCPU * 2 vCPU = $0.24/時間です。

モデル	vCPU	メモリ(GiB)	オンデマンド費	サポート費(1~2年目)	サポート費(3年目)	比率(1~2年目)	比率(3年目)
db.t3.micro	2	1	0.026	0.24	0.48	9.23	18.46
db.t3.small	2	2	0.052	0.24	0.48	4.62	9.23
db.t3.medium	2	4	0.104	0.24	0.48	2.31	4.62
db.t3.large	2	8	0.208	0.24	0.48	1.15	2.31
db.t3.xlarge	4	16	0.416	0.48	0.96	1.15	2.31
db.t3.2xlarge	8	32	0.832	0.96	1.92	1.15	2.31

インスタンスとサポートの単価を比較すると、 0.026 : 0.24 = 1:9.23、つまり、サポート費はインスタンス費の約9倍です。インスタンスに付随する延長サポートの費用を合算すると、従来の10倍かかります。

延長サポート単価が倍になる3年目の場合、従来の20倍です。

サポート期限の切れたMySQL/PostgreSQLをT系インスタンスで維持しようとするとTCOが高騰するため、十分な理由付けが必要です。

メジャーアップグレード方法

Amazon RDS延長サポート費用を認識していなかったり、サポート費用が想像以上に高いと判明したら、コスト削減のためにエンジンのメジャーアップグレードを検討しましょう。

メジャーアップグレードには、非互換な変更にともなう改修や性能評価が伴います。 Amazon RDS延長サポート分のコスト削減とメジャーアップグレードの対応コストを天秤にかけ、現状維持のために延長サポート費用を払い続けるのか、未来に投資してメジャーアップグレードするのか、決断しましょう。

AWSのマネージドの機能を利用してAurora/RDSをメジャーアップグレードする場合、インプレースとBlue/Greenの2方式があります。

手順を極限までシンプルにしたい場合は、インプレース方式がオススメです。

クラスターのバージョンを変更するだけで操作が完了します。ただし、操作開始とともに一連のメジャーアップグレード処理を一気通貫で行うため、ダウンタイムを含んだ移行が長時間に及び、ダウンタイム時間も読みづらいです。

ダウンタイムを抑えたい場合は、Blue/Greenデプロイ方式がオススメです。

異なるメジャーバージョン間でレプリケーションを張り、ダウンタイムはスイッチオーバーの一瞬だけです。エンドポイントの切り替えもフルマネージドで行われます。

Aurora・RDSの両方に対応し、切り戻しも簡単です。

データベースエンジンのメジャーバージョン間の差異は、公式ドキュメントを参照ください。

Amazon RDSサポート期間について

非常に大事な点として、Aurora/RDSのサービス、MySQL/PostgreSQLのデータベースエンジン、バージョンの差異によってサポート期間はまちまちであり、未定の期日もあるため、最新情報は以下のドキュメントを参照してください。

なお、Aurora/RDSに関係なく、延長サポートは「Amazon RDS Extended Support」とRDSが接頭します。 Auroraの文章や表でRDSが登場するのは少し気持ち悪いですが、気にしないようにしましょう。

以降では、Aurora/RDS MySQL/PostgreSQL のサポート期間について、直近で標準サポートの終了を控えているMySQL 5.7とPostgreSQL 11を例に確認します。

PostgreSQL 11のサポート期間

まずはPostgreSQL 11です。

PostgreSQL 11はAuroraとRDSで同じライフサイクルをたどります。標準サポートの終了を2024年2月末に迎えたあと、延長サポートモードになります。ただし、費用が発生するのは2024年4月以降です。

RDS Extended Support for PostgreSQL 11 starts on March 1, 2024, but will not be charged until April 1, 2024. Between March 1 and March 31, all PostgreSQL version 11 DB instances and clusters on RDS are covered under RDS Extended Support.

https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-release-calendar.html

延長サポート費用は1-2年目(year 1 pricing)と3年目(year 3 pricing)の2種類の価格設定があり、3年目は1-2年目の約2倍です。

2027年3月末に延長サポートが切れたあとはメジャーアップグレードされます。

MySQL 5.7のサポート期間

次にMySQL 5.7です。

MySQL 5.7はAuroraとRDSでライフサイクルが大きく異なります。

RDSの場合、標準サポートの終了を2024年2月末に迎えたあと、無償期間を挟まずに即時に有償の延長サポートが始まります。 3年目の2026年3月からはyear 3 pricingとなり、1年後の2023年2月末に延長サポートが切れたあとはメジャーアップグレードされます。

Auroraの場合、標準サポートの終了はRDSの8ヶ月後の2024年10月末です。そこから1ヶ月の無償期間を経て、2024年12月からyear 1 pricingの延長サポートが始まります。 year 3 pricingの開始時期は現時点では未定で、延長サポートの終了はRDSと同じく2027年2月末です。